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Beschreibung 

Betriebsverfahren fur einen Server und hiermit korrespondie- 
rende Gegenstande • 

5 

Die vorliegende Erfindung betrifft ein Betriebsverfahren fur 
einen Server , der mit einem Client kommuniziert , wobei der 
Server, wenn ihm vom Client eine Anforderung ftir eine Seite 
iibermittelt wird, die angeforderte Seite an den Client uber- 
10 mittelt. 

Die vorliegende Erfindung betrifft ferner einen Datentrager 
mit einem auf dem Datentrager gespeicherten Computerprogramm 
zur Durchfuhrung eines derartigen Betriebsverf ahrens . 

15 

Die vorliegende Erfindung betrifft weiterhin einen Server mit 
einem Massenspeicher, in dem ein Computerprogramm hinterlegt 
ist, so dass bei Aufruf des Computerprogramms von dem Server 
Rechner ein derartiges Betriebsverfahren ausfuhrbar ist. 

20 

Derartige Verfahren, Computerprogramme und Server sind allge- 
mein bekannt. Sie werden insbesondere bei Web-Anwendungen, 
z.B. bei Internet- und Intranet-Anwendungen, eingesetzt. 

25 Web-Anwendungen sind relativ anonym. Der Server und der 

Client wissen in aller Regel sehr .wenig voneinander. Insbe- 
sondere ist es dem Server in aller Regel nicht moglich, an- 
hand einer Anforderung fiir eine Seite ohne Weiteres zu ermit- 
teln, von welchem Client ihm diese Anforderung iibermittelt 

30 wurde und aus welchem Zustand des Clients heraus die Anforde- 
rung erfolgte. Jede an der Server gerichtete Anforderung muss 
daher in der Regel eine vollstandige Information ttber den an- 
fordernden Client und iiber die angeforderte Seite enthalten. 

35 Urn innerhalb einer Sitzung zwischen Server und Client (= Ses- 
sion) serverseitig dennoch gewisse Voreinstellungen (z.B. ei- 
ne Auswahl einer Sprache, die im Folgenden stets benutzt wer- 
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den soil) treffen zu kSnnen, ist es insbesondere bekannt, 
dass der Client sich zu Beginn der Sitzung beim Server anmel- 
det und dieser zusatzlich zur angeforderten Seite eine An- 
hSngseldatei (ein sogenanntes Cookie) an den Client ubermit- 
5 telt. Die Anhangseldatei wird vom Client jeder an diesen Ser- 
ver gerichteten Anforderung beigefugt. Sie wird also vom 
Client an den Server zuriick ubermittelt . Die Anhangseldatei 
ist dabei spezifisch fiir den Server. Sie wird vom Client also 
bei jeder an diesen Server gerichteten Anforderung mit an den 
10 Server ubermittelt. Die Ubermittlung der Anhangseldatei er- 
folgt so lange, bis entweder die Anhangseldatei auf Seiten 
des Clients geloscht wird oder vom Server eine neue Anhang- 
seldatei an den Client ubermittelt wird, so dass die bisheri- 
ge Anhangseldatei tiberschrieben wird. 

15 

Die Voreinstellungen, die getroffen werden sollen, konnen in 
der Anhangseldatei selbst enthalten sein. Alternativ kann die 
Anhangseldatei auch einen Link auf einen Speicherbereich im 
Server enthalten. In diesem Fall sind die Voreinstellungen 
20 als solche im Server gespeichert, wahrend sie im erstgenann- 
ten Fall im Client gespeichert sind. 

Der Zustand der Sitzung ist ublicherweise an die Sitzung im 
Sinne der Existenz des korrespondierenden clientseitigen Kom- 

25 munikationsprogramras, z.B. eines Internetbrowsers wie dem In- 
ternetexplorer von Microsoft, gebunden. Die Vorgehensweise 
des Standes der Technik funktioniert daher problemlos, solan - 
ge auf Seiten des Clients der Kommunikationsprozess erhalten 
bleibt und die Kommunikation mit dem Server uber ein einziges 

30 Fenster erfolgt 

Es ist aber allgemein bekannt, dass es moglich ist, in ein 
und demselben Internetbrowser parallel mehrere Fenster zu 
nutzen. Die Erzeugung mehrerer Fenster kann z. B. beim Inter- 
35 netexplorer von Microsoft durch Betatigen der Tastenkombina- 
tion "Steuerung N" oder durch wahlen der Option "Offnen in 
neuem Fenster" erfolgen. Auch in diesem Fall bereitet der 
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Standes der Technik noch keine Probleme, wenn auf Seiten des 
Clients zwar mehrere Fenster genutzt werden, in alien Fens- 
tern aber stets dieselben Voreinstellungen benutzt werden. 

5 Die Vorgehensweise des Standes der Technik versagt aber, wenn 
auf Seiten des Clients mit mehreren Fenstern gearbeitet wird 
und in den Fenstern voneinander verschiedene Voreinstellungen 
getroffen werden sollen. Denn wie bereits erwahnt, ist der 
Server nicht in der Lage, zu unterscheiden, von welchem der 
10 Fenster die jeweilige Anforderung an ihn Ubermittelt wurde. 

Dabei hilft auch die Verwendung der Anhangseldatei nicht wei- 
ter. Denn ein neues Fenster auf Seiten des Clients ist eben 
nur ein eigenes Fenster, nicht aber ein eigener Prozess. So- 
mit benutzen die Fenster die gleichen AnhSngseldateien. 

15 

Die Aufgabe der vorliegenden Erfindung besteht darin, ein Be- 
triebsverfahren ftir einen Server, ein hiermit korrespondie- 
rendes Computerprogramm und den entsprechenden Server zu 
schaffen, mittels derer derartige Voreinstellungen individu- 
20 ell ftir jedes clientseitige Fenster vorgenommen werden kon- 
nen. 

Die Aufgabe wird durch ein Betriebsverf ahren flir einen Ser- 
ver, der mit einem Client kommuniziert, dadurch gelost, 
25 - dass der Server, wenn ihm vom Client eine Anforderung fur 
eine Seite ubermittelt wird, die angeforderte Seite an den 
Client ubermittelt, 

- dass der Server der Seite Identif izierungsdaten derart bei- 
fugt, dass die Identif izierungsdaten bei einer weiteren An- 

30 forderung fur eine Seite vom Client dann und nur dann an 

den Server zurttck Ubermittelt werden, wenn die Anforderung 
auf Seiten des Clients von dieser Uberrnittlung der Seite 
ausgeht, 

- dass die Identif izierungsdaten zumindest einen ftir die 

35 Uberrnittlung der Seite spezifischen Obermittlungsidentif i- 
zierer umfassen, 
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- dass der Server die von ihm tibermittelten Identif izierungs- 
daten abspeichert, 

- dass der Server bei Erhalt der weiteren Anforderung den von 
ihm neu ubermittelten Obermittlungsidentif izierer anstelle 

5 des zurtick Obermittelten Obermittlungsidentifizierers ab- 
speichert f wenn der zuruck ubermittelte Obermittlungsiden- 
tifizierer mit einem abspeicherten Obermittlungsidentif i- 
zierer Obereinstimmt, und 

- dass der Server bei Erhalt der weiteren. Anforderung den von 
10 ihm neu Obermittelten Obermittlungsidentif izierer zusatz- 

lich zum zuruck Obermittelten Obermittlungsidentif izierer 
abspeichert, wehn der zuriick Obermittelte Obermittlungsi- 
dentif izierer mit keinem zuvor abspeicherten Obermittlung- 
sidentif izierer ubereinstimmt. 

15 

Durch diese Vorgehensweise kann der Server namlich zwar noch 
nicht erkennen, wenn auf Seiten des Clients ein zweites Fens- 
ter geoffnet wird (dazu spSter) . Er kann aber erkennen , wenn 
ihm vom Client "veraltete" Identif izierungsdaten ubermittelt 

20 werden. Anhand dieses Umstands, namlich dass die Identif izie- 
rungsdaten bereits veraltet bzw. uberholt sind, kann er daher 
erkennen, dass ein zweites Fenster ge6ffnet worden sein muss. 
Ab dem Zeitpunkt dieser Erkenntnis ist der Server somit in 
der Lage, dieses zweite Fenster getrennt vom ersten Fenster 

25 zu verwalten. 

Der Obermittlungsidentifizierer kann im einfachsten Fall eine 
laufende Nummer oder dergleichen sein. Vorzugsweise aber ist 
der Obermittlungsidentifizierer ein weltweit einmaliger Iden- 

30 tifikator. Beispielsweise kann der Obermittlungsidentifizie- 
rer ein sogenannter GUID sein. Ein GUID (global universal 
identifier) wird auf die - in der Regel auf eine Millisekunde 
genaue - Zeit des Servers sowie Identif ikationsdaten des Ser- 
vers gebildet, beispielsweise eine nur einmal vergebene Iden- 

35 tifikationsnummer der Netzwerkkarte des Servers oder des Pro- 
zessors des Servers. 
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Durch die erf inching sgemaiSe Vorgehensweise ist es beispiels- 
weise moglich, dass den Identif izierungsdaten Selektionsdaten 
zugeordnet sind und dass im Falle der Obereinstimmung des zu- 
ruck iibermittelten Obermittlungsidentif izierers mit einem der 
5 abgespeicherten Obermitt lungs identif izierer die vom Server 
auf Grund der weiteren Anforderung neu an den Client ubermit- 
telte Seite von den dem tibereinstiramenden Obermittlungsiden- 
tif izierer zugeordneten Selektionsdaten abhangt. 

10 Im Falle der Obereinstimmung des zuriick ttbertriittelten Ober- 
mittlungsidentif izierers mit keinem der abgespeicherten Ober- 
mittlungsidentifizierer sind verschiedene Vorgehensweisen 
m5glich. So kann beispielsweise eine vorbestimmte Startseite 
an den Client iibermittelt werden. Vorzugsweise aber hangt die 

15 vom Server auf Grund der weiteren Anforderung neu an den 

Client ubermittelte Seite von den einem der abgespeicherten 
Obermitt lungsidentif izierer zugeordneten Selektionsdaten ab. 
Diese Selektionsdaten ordnet der Server dann selbstverstand- 
lich auch dem zusatzlich abgespeicherten Obermittlungsidenti- 

20 fizierer zu. 

Vorzugsweise umfassen die Identif izierungsdaten auch einen 
Fensteridentifizierer. Im Falle der Obereinstimmung des zu- 
rttck Ubermittelten Obermittlungsidentif izierer mit einem der 

25 abgespeicherten Obermittlungsidentif izierer wird in diesem 

Fall der Fensteridentifizierer beibehalten. Wenn hingegen der 
zuruck ubermittelte Obermittlungsidentif izierer mit keinem 
der abgespeicherten Obermittlungsidentifizierer iiberein- 
stimmt f ordnet der Server dem zusatzlich abgespeicherten 

30 Obermittlungsidentifizierer einen neuen Fensteridentifizierer 
zu. 

Auf Grund dieser Vorgehensweise ist insbesondere eine effi- 
ziente Verwaltung von mehr als zwei clientseitigen Fenstern 
35 mSglich. Denn auf Grund dieser Vorgehensweise ist fur den 
Server erkennbar f welches Fenster clientseitig dupliziert 
wurde . 
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Auf Grund dieser Vorgehensweise ist es weiterhin moglich, 
dass im Falle der Obereinstimmung des zuriick ubermittelten 
Obermittlungsidentif izierers rait keinem der abgespeicherten 
Obermittlungsidentifizierer die vom Server auf Grund einer 
5 weiteren Anforderung neu an den client tibermittelte Seite von 
den Selektionsdaten abhangt, die demjenigen der abgespeicher- 
ten Obermittlungsidentifizierer zugeordnet sind, dessen Fen- 
steridentif izierer rait dem zuriick iiberraittelten Fensteriden- 
tif izierer iibereinstimmt . 

10 

Der neue Fensteridentif izierer kann - analog zura Obermitt- 
lungsidentifizierer - im einfachsten Fall wieder eine laufen- 
de Nummer sein. Vorzugsweise ist aber auch er als GUID ausge- 
bildet. Dabei kann er alternativ als eigenstandig generierter 
15 GUID ausgebildet sein oder mit dem unmittelbar zuvor gene- 
rierten Obermittlungsidentifizierer identisch sein. 

Der Server verwaltet die Identif izierungsdaten vorzugsweise 
in Form einer Tabelle, die pro Zeile die EintrSge Fenster- 
20 identifizierer, Obermittlungsidentifizierer und Selektionsda- 
ten enthalt. Anstelle der Selektionsdaten selbst kann in der 
Tabelle selbstverstandlich auch ein Verweis (= Pointer) auf 
die Selektionsdaten gespeichert sein. 

25 Die Prufungsreihenfolge (erst die Obermittlungsidentifizierer 
oder erst die Fensteridentif izierer) ist prinzipiell in das 
Belieben des Fachmanns gestellt. Vorzugsweise wird aber zu- 
erst der Fensteridentif izierer uberprttft und dann der fUr 
diesen Fensteridentif izierer gespeicherte Obermittlungsiden- 

30 tif izierer. Denn der vom Client zuriick ubermittelte Fenster- 
identif izierer ist stets abgespeichert . Der vom Client zuriick 
Ubermittelte Obermittlungsidentifizierer hingegen kdnnte be- 
reits tiberschrieben sein. 

35 Bei Web-Anwendungen sind im Wesent lichen zwei Arten der An- 
forderungstibermittlung bekannt, n^mlich die sogenannten Post- 
Requests und die sogenannten Get-Requests. 
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Post-Requests beruhen auf dem Prinzip, dass der Client Einga- 
befelder der Seite ausftillt und dann die ausgefiillten Einga- 
bef elder vom Client an den Server zuruck tibermittelt werden. 
Bei Post-Requests werden dabei vom Client stets alle Eingabe- 
5 f elder an den Server zuruck tibermittelt. Die iibermittelten 
Daten enthalten unter anderem die Anforderung ftir die neue 
Seite. Ftir eine im Sinne der vorliegenden Erfindung ordnungs- 
gemalie serverseitige Behandlung solcher Post-Requests ist es 
daher beispielsweise moglich, dass der Server die Identifi- 

10 zierungsdaten der Obermittelten Seite als versteckte, auf 
Seiten des Clients nicht mit angezeigte Eingabefelder bei- 
ftigt. Erf indungsgemSfl werden also der Seite versteckte Einga- 
befelder beigeftigt, die bei einer ublichen Darstellung der 
Seite in einem Fenster des Clients nicht mit angezeigt wer- 

15 den. In diesen Eingabef eldern sind von Seiten des Servers be- 
reits vorab die Identif izierungsdaten hinterlegt worden. Sie 
werden daher vom Client an den Server zurtick tibermittelt, 
wenn der Client einen Post-Request sendet. 

20 Bei Get-Requests hingegen wird vom Client unmittelbar eine 
Linkadresse, in der Regel eine sogenannte URL, an den Server 
zuruck tibermittelt. Die Linkadresse ist dabei Bestandteil der 
zuvor tibermittelten Seite und wird in dem Fenster, in dem der 
Client die Seite darstellt, als solche mit angezeigt. Selek- 

25 tiert der Benutzer des Clients diese Linkadresse, stellt die 
Linkadresse selbst und unmittelbar eine Anforderung fur eine 
weitere Seite dar. 

Wenn die Seite mindestens eine derartige Adresse ftir eine 
30 weitere Seite enthait, kann eine im Sinne der vorliegenden 
Erfindung ordnungsgemafte serverseitige Behandlung eines sol- 
chen Get-Requests dadurch erreicht werden, dass der Server 
die Identif izierungsdaten der tibermittelten Seite als der Ad- 
resse zugeordnete Parameter, sogenannte Query-Parameter, bei- 
35 fflgt. 
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Ein Spezialfall einer Reaktion des Servers auf den Erhalt ei- 
ner Anforderung ist ein sogenannter serverseitiger Response- 
Redirect. Ein serverseitiger Response-Redirect liegt vor, 
wenn der Server auf Grund einer an ihn tibermittelten Anforde- 
5 rung nicht die angeforderte Seite an den Client ubermittelt, 
sondern bei Erhalt der weiteren Anforderung zunachst eine 
dritte, vom Client wieder an den Server zuruck zu sendende 
Anforderung an den Client ubermittelt. Erst auf Grund der 
Obermittlung der dritten Anforderung an den Server ubermit- 
10 telt der Server dann die angeforderte Seite. In diesem Fall 
gibt es zwei Mdglichkeiten, serverseitig eine im Sinne der 
vorliegenden Erfindung ordnungsgemaBe Behandlung der Anforde- 
rung zu gewahrleisten. 

15 Zum einen ist es moglich, dass der Server die Identifizie- 
rungsdaten der dritten Anforderung als zugeordnete Parameter 
beifligt. In diesem Fall werden die Identif izierungsdaten der 
Anforderung selbst beigefugt. Alternativ ist es auch moglich, 
dass der Server die Identif izierungsdaten der dritten Anfor- 

20 derung als AnMngseldatei beifugt, die vom Client nicht der 
dritten Anforderung an den Server zuruck tibermittelt mit. In 
diesem Fall ftigt der Server die Identif izierungsdaten der 
dritten Anforderung also als sogenanntes Transf ercookie bei. 
Die Identif izierungsdaten sind der Seite dabei wie auch bei 

25 Post-Requests als versteckte Daten beigefugt. Das Programm 
extrahiert die Identif izierungsdaten und fugt sie in die An- 
hSngseldatei ein. Weiterhin Ubermittelt der Server zusammen 
mit der Seite, die er auf Grund der dritten Anforderung an 
den Client ubermittelt, einen Loschbefehl fur diese Anhang- 

.30 seldatei an den Client. 

Es gibt Sprachen, bei denen den vom Server an den Client 
ubermittelt en Seiten Programme beigefugt bzw. die Programme 
in diese Seiten eingebettet sein konnen. Ein Beispiel einer 
35 solchen Sprache ist JavaScript. In diesem Fall gibt es eine 
weitere Moglichkeit, zu gewahrleisten, dass die Identif izie- 
rungsdaten zusammen mit der Anforderung vom Client an den 
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Server ubermittelt werden. Denn in diesem Fall ist es mdg- 
lich, dass der Server die Identif izierungsdaten der Seite da- 
durch beifugt, dass er der Seite ein Programm beifugt, auf 
Grund dessen der Client einer Anforderung ftir eine Seite dann 
5 und nur dann eine die Identif izierungsdaten enthaltende An- 
hangseldatei beifugt, wenn die Anforderung von dieser Ober- 
mittlung der Seite ausgeht. 

In diesem Fall wird also ebenfalls ein sogenanntes Transfer- 
10 cookie erzeugt. Die Erzeugung des Transfercookies erfolgt 
aber im Gegensatz zum Response-Redirect nicht serverseitig, 
sondern clientseitig. 

Der Server kann nicht unmittelbar erkennen, wenn auf Seiten 

15 des Clients eine Duplizierung einer bereits an den Client 
ubertragenen Seite erfolgt. Wenn daher der Benutzer des 
Clients eine Seite dupliziert und danach langere Zeit mit nur 
einer der beiden Versionen der duplizierten Seite arbeitet, 
die andere Version der duplizierten Seite aber nicht verSn- 

20 dert, bleibt diese andere Version vorerst unverandert erhal- 
ten. Wenn der Benutzer des Clients dann zu einem erheblich 
spateren Zeitpunkt von der anderen, noch unver^nderten Versi- 
on der duplizierten Seite eine Anforderung an den Server sen- 
det, uberniramt der Server in diesem Fall die Selektionsdaten, 

25 die der ver&nderten Version der duplizierten Seite zu diesem 
Zeitpunkt zugeordnet sind. Die Selektionsdaten konnen zu die- 
sem Zeitpunkt aber bereits erheblich geandert worden sein. 
Die Restaurierung des vom Benutzer eigentlich gewtinschten Zu- 
stands der anderen Version der duplizierten Seite kann ftir 

30 den Benutzer daher relativ aufwandig sein, Aus diesem Grund 
ist es von Vorteil, so friih wie moglich zu erkennen, wenn auf 
Seiten des Clients eine bereits an diesen ubermittelte Seite 
dupliziert wird. 

35 Ein sofortiges Erkennen eines solchen Duplizierens ist da- 
durch moglich, 
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- dass der Server der Seite auch eine Variable mit einem An- 
fangswert und ein vom Client beim Darstellen der Seite in 
einem Fenster auszufuhrendes Programm beifugt, 

- dass der Client auf Grund des Prograinms den Wert der Vari- 
5 able, wenn sie den Anfangswert aufweist, abandert und 

- dass der Client auf Grund des Programms die vorherige An- 
forderung zur Obermittlung der Seite wiederhQlt, so dass 
der Client, wenn die Variable nicht den Anfangswert auf- 
weist, die bei der vorherigen Anforderung tibermittelten 

10 Identifizierungsdaten ein zweites Mai an den Server uber- 
mittelt . 

Denn dann wiederholt der Client die vorherige Anforderung so- 
fort beim Duplizieren der Seite, so dass der Server die Dup- 

15 lizierung als solche sofort erkennen kann. Der Server erkennt 
bei dieser Vorgehensweise zwar auch dann (falschlicherweise) 
eine Duplizierung, wenn der Benutzer des Clients - ohne die 
Seite zu duplizieren - diese nuf aktualisiert oder auf eine 
clientseitig noch gespeicherte, in diesem Fenster aber nicht 

20 mehr angezeigte Seite zuriick greift. Dies ist aber unkri- 

tisch, da in diesem Fall auf Seiten des Servers lediglich ein 
Fenster* verwaltet wird, das auf Seiten des Clients in der Re- 
alitat gar nicht existent ist. Hingegen kann es nicht gesche- 
hen, dass auf Seiten des Clients ein Fenster dupliziert wird 

25 und der Server dies nicht erkennt. Die Anforderung kann dabei 
je nach Anwendungsfall in Form eines Post- oder in Form eines 
Get-Requests an den Server ubermittelt werden. Dies gilt auch 
dann, wenn das erstmalige Laden der Seite auf Grund eines 
Post-Requests erfolgte. 

30 

Das erfindungsgemaiie Betriebsverf ahren ist als Computerpro- 
gramm realisiert, das dem Server zugefuhrt wird. Das Compu- 
terprogramm wird dem Server dabei tiber einen DatentrSger zu- 
geftthrt. Beispiele eines derartigen Datentragers sind eine 
35 CD-ROM oder eine Streamerkassette. Auf dem DatentrSger ist 
das Computerprogramm in (ausschliefilich) maschinenlesbarer 
Form gespeichert. Das Computerprogramm kann auf dem Datentra- 
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ger dabei alternativ in komprimierter oder in unkomprimierter 
Form gespeichert sein. 

Der Datentrager mit dem darauf gespeicherten Computerprogramm 
5 wird in ein LesegercLt eingeftihrt, mittels dessen der Server 
das auf dem Datentrager gespeicherte Computerprogramm lesen 
kann. Er liest daher das Computerprogramm vom Datentrager aus 
und speichert es in einem Massenspeicher ab, beispielsweise 
auf einer Festplatte. Bei Aufruf des Compute rprogramms von 
10 der Festplatte (alternativ auch vom Datentrager) ist der Ser- 
ver daher in der Lage, das erf indungsgemafie Betriebsverf ahren 
auszufuhren. 

Weitere Vorteile und Einzelheiten ergeben sich aus der nach- 
15 folgenden Beschreibung eines Ausfiihrungsbeispiels in Verbin- 
dung mit den Zeichnungen. Dabei zeigen 

FIG 1 einen Rechnerverbund, 

FIG 2 ein Ablauf diagramm, 

20 FIG 3 eine Tabelle und 

FIG 4 bis 7 weitere Ablauf diagramme . 

GemaJJ FIG 1 ist ein Server 1 tiber eine Rechner-Rechner-Ver- 
bindung 2 mit einem Client 3 datentechnisch verbunden. Die 
25 Rechner-Rechner-Verbindung 2 kann dabei auf verschiedene Art 
ausgebildet sein. In der Regel ist sie jedoch als Internet- 
oder als Intranet -Verbindung ausgebildet. Ober die Rechner- 
Rechner-Verbindung 2 konnen der Server 1 und der Client 3 ge- 
m£fi einem Web-Protokoll miteinander kommunizieren. 

30 

Der Server 1 weist, wie allgemein iiblich, mehrere Komponenten 
4 bis 8 auf f die tiber einen Bus 9 miteinander verbunden sind. 
Die Komponenten 4 bis 8 umfassen insbesondere einen Prozessor 
4, einen Massenspeicher 5 (typisch eine oder mehrere Fest- 
35 platten) , ein Lesegerat 6, einen Zeitgeber 7 und eine Netz- 
werkkarte 8. 
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In das Lesegerat 6 ist ein Datentrager 10 einfiihrbar, auf dem 
in ausschlielilich maschinenlesbarer Form ein Computerprogramm 
11 gespeichert ist. Dieses Computerprogramm 11 wird von dem 
Datentrager 10 ausgelesen und, wie in FIG 1 gestrichelt ange- 
5 deutet ist f im Massenspeicher 5 hinterlegt. Bei Aufrufdes 
Computerprogramms 11 ist der Server 1 daher in der Lage, das 
Computerprogramm 11 auszufiihren. Bei Aufruf des Computerpro- 
gramms 11 fiihrt der Server 1 dabei ein Betriebsverfahren aus, 
das nachfolgend in Verbindung mit FIG 2 naher beschrieben 
10 wird. 

GemaJS FIG 2 nimmt der Server 1 in einem Schritt SI vom Client 
3 eine Anmeldung und eine erste Anforderung ftir eine Seite 
entgegen. Der Server 1 ermittelt daraufhin in einem Schritt 
15 S2 einen Obermittlungsidentif izierer Obld. Der Obermittlungs- 
identif izierer Obld ist dabei vorzugsweise weltweit einmalig. 
Beispielsweise kann er aus einer Kombination der vom Zeitge- 
ber 7 ausgegebenen Zeit und dem Code der Netzwerkkarte 8 
urid/oder des Prozessors 4 bestehen. 

20 

In einem Schritt S3 wird sodann ein Fensteridentif izierer 
Feld gleich dem soeben ermittelten Obermittlungsidentif izie- 
rer Obld gesetzt. Die beiden Identif izierer Obld, Feld werden 
sodann - siehe erganzend FIG 3 - in die erste Zeile einer Ta- 
25 belle 12 eingetragen. Gemafi FIG 3 k6nnen dabei jeder Zeile 
der Tabelle 12 aufier den beiden Identif izierern Obld, Feld 
auch noch Selektionsdaten SD zugeordnet werden. Auf die Be- 
deutung der Selektionsdaten SD wird nachstehend noch einge- 
gangen werden. 

30 

In einem Schritt S5 ftigt der Server 1 der angef orderten Seite 
die Identif izierungsdaten Feld, Obld bei. Die BeifOgung er- 
folgt dabei derart, dass die Identif izierungsdaten Feld, Obld 
bei einer weiteren Anforderung far eine Seite vom Client 3 
35 dann und nur dann an den Server 1 zuruck Obermittelt werden, 
wenn die Anforderung auf Seiten des Clients 3 von der Ober- 
mittlung dieser Seite ausgeht. 
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Gemafi einem Schritt S6 fiigt der Server 1 weiterhin der ange- 
. forderten Seite eine Variable und ein Programm bei. Die Vari- 
abel weist einen Anfangswert auf . Das Programm ist derart 
ausgestaltet, dass es bei einem clientseitigen Kopieren der 
5 ubertragenen Seite eine Neuanf orderung der bisherigen Seite 
auslSst. Hierauf wird spater noch nSher eingegangen werdeni 
Der Schritt S6 ist dabei nur optional und daher in FIG 2 nur 
gestrichelt dargestellt. In einem Schritt S7 iibermittelt der 
Server 1 sodann die angeforderte Seite einschliefllich der 
10 dieser Seite beigefugten Inf ormationen an den Client 3. Bei 

den beigeftigten Informationen handelt es sich insbesondere urn 
die beiden beigefugten Identif izierer Obld, Feld, deren Er- 
ganzungen sowie die Variable und das Programm. 

15 In einem Schritt S8 nimmt der Server 1 vom Client 3 eine wei- 
tere Eingabe entgegen. Der Server 1 iiberpriift daraufhin zu- 
nachst in einem Schritt S9, 'ob der Client 3 sich abgemeldet 
hat. Wenn dies der Fall ist, I5scht er in einem Schritt S10 
die Tabelle 12 und beendet die Ausfuhrung des Verfahrens. 

20 

Wenn die Eingabe des Schrittes S8 keine Abmeldung war, war 
sie eine neue Anf orderung. In diesem Fall extrahiert der Ser- 
ver 1 aus der ubermittelten Anforderung die zurttck iibermit- 
telten Identif izierer 0bld f Feld sowie die Selektionsdaten 
25 SD. 

In einem Schritt S12 uberprtift der Server 1 sodann, ob der 
zuriick ubermittelte Obermittlungsidentif izierer Obld mit dem 
Obermittlungsidentif izierer Obld iibereinstimmt, der in der 

30 Tabelle 12 dem zuriick ubermittelten Fensteridentif izierer 
Feld zugeordnet ist. Der besseren Obersichtlichkeit halber 
ist der Schritt S12 in FIG 2 dabei in zwei Teilschritte S12a, 
S12b aufgeteilt. Im Teilschritt S12a wird eine logische Vari- 
able entsprechend der vorzunehmenden Prufung belegt, im Teil- 

35 schritt S12b die logische Variable abgefragt. 
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Wenn im Schritt S12 eine Obereinstimmung ermittelt wurde, 
geht die vom Client 3 iibermittelte Anforderung von einera ser- 
verseitig bereits erfassten und verwalteten Fenster des 
Clients 3 aus. In diesem Fall wird in einem Schritt S13 ana- 
5 log zum Schritt S2 ein neuer Obermittlungsidentif izierer Obld 
ermittelt und in der Tabelle 12 in der Zeile abgespeichert, 
in der auch der zurtick iibermittelte Fensteridentif izierer 
Feld abgespeichert ist. Der Server 1 speichert also den neu 
ermittelten Obermittlungsidentif izierer Obld anstelle des zu- 
10 ruck ubermittelten Obermittlungsidentif izierer Obld in der 
Tabelle 12 ab. 

Wenn im Schritt S12 hingegen keine Obereinstimmung festge- 
stellt wurde, wird ein Schritt S14 ausgefiihrt. Im Schritt S14 

15 wird ebenfalls der Obermittlungsidentif izierer Obld analog 

zur Vorgehensweise von Schritt S2 neu ermittelt. Sodann wird 
aber der Fensteridentif izierer Feld analog zum Schritt S3 
gleich dem soeben neu ermittelten Obermittlungsidentif izierer 
Obld gesetzt. Beide Identif izierer Feld, Obld werden vom Ser- 

20 ver 1 in eine neue Zeile der Tabelle 12 eingetragen. Ferner 
werden im Rahmen des Schrittes S14 noch die Selektionsdaten 
SD, die dem zuruck ubermittelten Fensteridentif izierer Feld 
zugeordnet sind, in die nunmehr neu belegte Zeile der Tabelle 
12 kopiert. 

25 

Falls der Server 1 neue Selektionsdaten SD erhalten hat, £n- 
dert er ferner in einem Schritt S15 die Selektionsdaten SD 
ab, die dem aktuellen Fensteridentif izierer Feld zugeordnet 
sind. Je nach dem, ob auf Grund der Prufung im Schritt S12 
30 der Schritt S13 oder der Schritt S14 durchlaufen wurde, han- 
delt es sich dabei urn den zuruck ubermittelten Fensteridenti- 
fizierer Feld oder urn den neu ermittelten Fensteridentif izie- 
rer Feld. 

35 In einem Schritt SI 6 tiberpriift der Server 1 als nachstes, ob 
er die angeforderte Seite direkt ubermitteln kann oder ob er 
ein sogenanntes Response-Redirect durchfiihren muss. Wenn er 
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ein Response-Redirect durchfiihren muss, ftihrt er einen 
Schritt S17 aus, in dem er eine neue Adresse, in der Regel 
eine URL-Adresse zuziiglich des aktuellen Fensteridentif izie- 
rers Feld und des aktuellen Obermittlungsidentif izierers Obld 
5 an den Client 3 ubermittelt . Sodann springt er zum Schritt S8 
zuruck, 

Anderenfalls ermittelt der Server 1 anhand der Selektionsda- 
ten, die dem aktuellen Fensteridentif izierer Feld und dem ak- 
10 tuellen Obermittlungsidentifizierer Obld in der Tabelle 12 
zugeordnet sind, welche Seite an den Client 3 Ubermittelt 
werden soil. Alternativ oder erganzend kann auch der Inhalt 
der Seite modifiziert werden. Sodann springt der Server 1 zum 
Schritt S5 zurtick. 

15 

FIG 4 zeigt eine erste MSglichkeit, die Identif izierungsdaten 
Obld, Feld der zu ubermittelnden Seite beizufugen. GemaB FIG 
4 fugt der Server 1 der Seite die Identif izierer Obld, Feld 
in einem Schritt. S19 zunSchst als versteckte Eingabef elder 
20 bei. Dadurch ergibt sich die Wirkung, dass die Identif izierer 
Obld und Feld bei jedem Post-Request des Clients 3, der von 
dieser Seite ausgeht, vom Client 3 an den Server 1 ubermit- 
telt werden. 

25 In einem Schritt S20 tiberprttft der Server 1 sodann, ob die zu 
ubermittelnde Seite eine URL-Adresse enthalt, der die Identi- 
fizierer Obld und Feld noch nicht als Query-Parameter beige- 
fiigt wurden. Wenn dies der Fall ist, fuhrt der Server 1 einen 
Schritt S21 aus, in dem er dieser Adresse die Identif izierer 

30 Obld und Feld als Query-Parameter beifugt. Vom Schritt S21 
geht der Server dann zum Schritt S20 zurtick. Der Schritt S20 
ist dabei in FIG 4 - analog zum Schritt S12 von FIG 2 - in 
zwei Teilschritte unterteilt. 

35 FIG 5 zeigt eine weitere MSglichkeit, die Identif izierungsda- 
ten Obld, Feld der Seite beizufiigen. Gemaft FIG 5 ftigt der 
Server 1 der Seite die Identif izierer Obld und Feld als ver- 
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steckte Daten bei. Dabei kann es sich - analog zum Schritt 
S19 von FIG 4 - urn versteckte Eingabef elder handeln. Dies ist 
aber nicht zwingend erforderlich. Sodann fugt der Server 1 
der Seite ein Programm bei, das bei einer Anforderung des 
5 Clients 3, die von dieser Seite ausgeht, ausgefUhrt wird. Auf 
Grund des Prograirans extrahiert dann der Client 3 aus dieser 
Seite die Identif izierungsdaten Obld, Feld und bindet sie in 
ein von ihm zu kreierendes Cookie ein. Das Cookie sendet der 
Client 3 zusammen mit der Anforderung an den Server 1. 

10 

FIG 6 zeigt die Mdglichkeiten, die bestehen, urn den Schritt 
S17 von FIG 2, in dem die Identif izierer Feld und Obld der zu 
ubermittelnden URL beigefiigt werden, zu implementieren. Gem&fi 
FIG 6 ist es mdglich, den Schritt S17 derart auszugestalten, 

15 dass die Identif izierer Obld und Feld - analog zum Schritt 

S21 von FIG 4 - der URL-Adresse als Query-Parameter beigefiigt 
werden. Alternativ ist es moglich, dass der Server 1 im 
Schritt S17 der URL-Adresse eine Anh&ngseldatei (Cookie) bei- 
fiigt, welche die Identif izierer Obld, Feld enthalt. In diesem 

20 letzteren Fall sollten die im Schritt S7 (siehe FIG 2) der 

angef orderten Seite beigefUgten Informationen an den Client 3 
einen Loschbefehl enthalten, auf Grund dessen diese Anhang- 
seldatei auf Seiten des Clients 3 sofort wieder geloscht 
wird. 

25 

Von den in FIG 6 dargestellten Schritten S17 wird stets nur 
einer ausgefuhrt. Die beiden Schritte S17 sind daher in FIG 6 
gestrichelt dargestellt. 

30 FIG 7 zeigt nun der Vollstandigkeit halber das Verfahren, das 
der Client 3 auf Grund des Programms ausfiihrt, das vom Server 
1 im Rahmen des Schrittes S6 (siehe FIG 2) der angef orderten 
Seite beigefiigt wird. Das Programm wird dabei vom Client 3 
stets ausgefuhrt, wenn die Seite von ihm in einem Fenster 

35 dargestellt wird. Das Programm wird also sowohl dann ausge- 
fUhrt, wenn der Client 3 die Seite erstmals erhalt, als auch 
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dann, wenn der Client 3 die Seite beispielsweise mit "Steue- 
rung N" dupliziert. 

Gemali FIG 7 extrahiert der Client 3 zunachst aus der Seite 
5 die ubermittelte Variable, In einem Schritt S25 uberprtift er 
dann, ob die Variable noch ihren Anfangswert hat. Wenn dies 
der Fall ist, setzt er die Variable in einem Schritt S26 auf 
ihren Endwert. Der Endwert muss dabei selbstverstandlich vom 
Anfangswert verschieden sein. Ansonsten kann er beliebig ge- 

10 wahlt sein. Wenn die Prufung im Schritt S25 keine Oberein- 
stimmung ergeben hat, fUhrt der Client 3 einen Schritt S27 
aus, in dem er die vorherige Anforderung wiederholt. Die Wie- 
derholung der Anforderung bewirkt dabei insbesondere, dass 
die bereits an den Server 1 zuriick ubermittelten Identif izie- 

15 rungsdaten tibld, Feld ein zweites Mai an den Server 1 uber- 
mittelt werden. Dadurch ist dann der Server 1 sofort in der 
Lage, zu erkennen f dass clientseitig ein neues Fenster geoff- 
net wurde. 

20 Mittels des erf indungsgemafien Betriebsverfahrens ist es somit 
auf einfache Weise moglich, dass der Server 1 individuell 
mehrere Fenster des Clients 3 verwaltet. 
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Patentansprtiche 

1. Betriebsverfahren ftir einen Server (1), der mit einem 
Client (3) kommuniziert, 

5 - wobei der Server (1) , wenn ihm vom Client (3) eine Anforde- 
rung ftir eine Seite ubermittelt wird, die angeforderte Sei- 
te an den Client (3) iibermittelt, 

- wobei der Server (1) der Seite Identif izierungsdaten (Obld, 
Feld) derart beifugt, dass die Identif izierungsdaten (Obld, 

10 Feld) bei einer weiteren Anforderung fur eine Seite vom 

Client (3) dann und nur dann an den Server (1) zuruck iiber- 
mittelt werden, wenn die Anforderung auf Seiten des Clients 
(3) von dieser Obermittlung der Seite ausgeht, 

- wobei die Identif izierungsdaten (Obld, Feld) zumindest ei- 
15 nen fur die Obermittlung der Seite spezifischen Obermitt- 

lungsidentifizierer (Obld) umfassen, 

- wobei der Server (1) die von ihm Ubermittelten Identifizie- 
rungsdaten (Obld) abspeichert, 

- wobei der Server (1) bei Erhalt der weiteren Anforderung 
20 den von ihm neu ubermittelten Obermittlungsidentif izierer 

(Obld) anstelle des zuruck ubermittelten Obermittlungsiden- 
tif izierer s (Obld) abspeichert, wenn der zurtick ubermittel- 
te Ubermittlungsidentifizierer (Obld) mit einem abspeicher- 
ten Obermittlungsidentifizierer (Obld) ubereinstimmt, und 

25 - wobei der Server (1) bei Erhalt der weiteren Anforderung 
den von ihm neu tibermittelten Obermittlungsidentifizierer 
(Obld) zusatzlich zum zuruck ubermittelten Obermittlungsi- 
dentifizierer (Obld) abspeichert, wenn der zuruck ubermit- 
telte Obermittlungsidentifizierer (Obld) mit keinem zuvor 

30 abspeicherten Obermittlungsidentifizierer (Obld) tiberein- 
stimmt . 

2. Betriebsverfahren nach Anspruch 1, 
dadurch gekennzeichnet f 

35 dass den Identif izierungsdaten (Obld, Feld) Selektionsdaten 
(SD) zugeordnet sind und dass im Falle der Obereinstimmung 
des zuruck ubermittelten Obermittlungsidentif izierers (Obld) 
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mit einem der abgespeicherten Obermittlungsidentif izierer 
(Obld) die vom Server (1) auf Grund der weiteren Anforderung 
neu an den Client (3) ubermittelte Seite von den dem iiberein- 
stimmenden Obermittlungsidentif izierer (Obld) zugeordneten 
5 Selektionsdaten (SD) abhangt. 

3. Betriebsverfahren nach Anspruch 2, 
dadurch gekennzeichnet, 

dass im Falle der Obereinstimmung des zurttck ubermittelten 
10 Obermittlungsidentifizierers (Obld) mit keinem der abgespei- 
cherten Obermittlungsidentif izierer (Obld) die vom Server (1) 
auf Grund der weiteren Anforderung neu an den Client (3) 
ubermittelte Seite von den einem der abgespeicherten Ober- 
mittlungsidentif izierer (Obld) zugeordneten Selektionsdaten 
15 (SD) abhangt und dass der Server (1) diese Selektionsdaten 

(SD) dem zusatzlich abgespeicherten Obermittlungsidentif izie- 
rer (Obld) zuordnet. 

4. Betriebsverfahren nach Anspruch 1, 2 oder 3, 
20 dadurch gekennzeichnet, 

- dass die Identif izierungsdaten (Obld, Feld) auch einen 
Fensteridentif izierer (Feld) umf assen, 

- dass der Server (1) im Falle der Obereinstimmung des zuriick 
ubermittelten Obermittlungsidentifizierers (Obld) mit einem 

25 der abgespeicherten Obermittlungsidentif izierer (Obld) den 
Fensteridentif izierer (Feld) des ubereinstimmenden Ober- 
mittlungsidentifizierers (Obld) beibehait und 

- dass der Server im Falle der Obereinstimmung des zuriick 
ubermittelten Obermittlungsidentifizierers (Obld) mit kei- 

30 nerd der abgespeicherten Obermittlungsidentif izierer (Obld) 
dem zusatzlich abspeicherten Obermittlungsidentif izierer 
(Obld) einen neuen Fensteridentif izierer (Feld) zuordnet. 

5. Betriebsverfahren nach Anspruch 3 und 4, 
35 dadurch gekennzeichnet, 

dass im Falle der Obereinstimmung des zuriick ubermittelten 
Obermittlungsidentifizierers (Obld) mit keinem der abgespei- 
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cherten Obermittlungsidentif izierer (Obld) die vom Server (1) 
auf Grund einer weiteren Anforderung neu an den Client (3) 
ubermittelte Seite von den Selektionsdaten (SD) abhangt, die 
demjenigen der abgespeicherten Obermittlungsidentif izierer 
5 (Obld) zugeordnet sind, dessen Fensteridentif izierer (Feld) 
mit dem zurUck abermittelten Fensteridentif izierer (Feld) 
Obereinstimmt . 

6. Betriebsverfahren nach einem der obigen Anspruche, 
10 dadurch gekennzeichnet, 

dass der Server (1) die Identif izierungsdaten (Obld, Feld) 
der iibermittelten Seite als versteckte, auf Seiten des 
Clients (3) nicht mit angezeigte Eingabef elder beiftigt. 

15 7. Betriebsverfahren nach einem der obigen Anspruche, 
dadurch gekennzeichnet, 
dass die Seite mindestens eine Adresse fur eine weitere Seite 
enthalt und dass der Server (1) die Identif izierungsdaten 
(Obld, Feld) der abermittelten Seite als der Adresse zugeord- 

20 nete Parameter beifugt. 

8. Betriebsverfahren nach einem der obigen Ansprache, 
dadurch gekennzeichnet, 
dass der Server (1) bei Erhalt der weiteren Anforderung zu- 
25 nachst eine dritte, vom Client (3) wieder an den Server (1) 
zuruck zu sendende Anforderung an den Client (3) abermittelt 
und dass der Server (1) die Identif izierungsdaten (0bld f 
Feld) der dritten Anforderung als zugeordnete Parameter bei- 
fttgt. 

30 

9- Betriebsverfahren nach einem der obigen Anspruche, 
dadurch gekennzeichnet, 
dass der Server (1) bei Erhalt der weiteren Anforderung zu- 
nachst eine dritte, vom Client (3) wieder an den Server (1) 
35 zurack zu sendende Anforderung an den Client (3) abermittelt, 
dass der Server (1) die Identif izierungsdaten (Obld, Feld) 
der dritten Anforderung als Anhangseldatei beiftigt, die vom 
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Client (3) mit der dritten Anforderung an den Server (1) zu- 
rtick tibermittelt wird, und dass der Server (1) zusammen mit 
der auf Grund der dritten Anforderung an den Client (3) uber- 
mittelten Seite einen Loschbefehl fur diese Anhangseldatei an 
5 den Client (3) tibermittelt . 

10. Betriebsverfahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

dass der Server (1) die Identif izierungsdaten (Ubld, Feld), 
10 der Seite dadurch beifiigt, dass er der Seite ein Programm 
beifugt, auf Grund dessen der Client (3) einer Anforderung 
fiir eine Seite dann und nur dann eine die Identif izierungsda- 
ten (Ubld, Feld) enthaltende Anhangseldatei beifiigt, wenn die 
Anforderung von dieser Obermittlung der Seite ausgeht. 

15 

11. Betriebsverfahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

- dass der Server (1) der Seite auch eine Variable rait einem 
Anfangswert und ein vom Client (3) beim Darstellen der Sei- 

20 te in einem Fenster auszuftihrendes Programm beifiigt, 

- dass der Client (3) auf Grund des Programms den Wert der 
Variable, wenn sie den Anfangswert aufweist, abandert und 

- dass der Client (3) auf Grund des Programms die vorherige 
Anforderung zur Obermittlung der Seite wiederholt, so dass 

25 der Client (3), wenn die Variable nicht den Anfangswert 

aufweist, die bei der vorherigen Anforderung iibermittelten 
Identifizierungsdaten (Obld, Feld) ein zweites Mai an den 
Server (1) tibermittelt. 

30 12. DatentrSger mit einem auf dem DatentrSger gespeicherten 
Computerprogramm (11) zur Durchfuhrung eines Betriebsverfah- 
rens nach einem der obigen Anspriiche. 

13. Server mit einem Massenspeicher (5), in dem ein Computer- 
35 programm (11) hinterlegt ist, so dass bei Aufruf des Compu- 
terprogramms (11) von dem Server ein Betriebsverfahren nach 
einem der Anspriiche 1 bis 11 ausfiihrbar ist. 
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FIG 5 
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